DNS Resolvers and their Clients

The Domain Name System (DNS) performs an essential Internet duty: the translation of host names, which are convenient for humans, into IP addresses, which are used to route packets. To do so, an application on an end-user’s system must contact a DNS resolver to perform these translations. While the user’s system may run a DNS resolver locally, many use an ISP resolver (sometimes called a DNS cache) to perform the resolution on the client’s behalf. This resolver then must proceed through a series of queries to locate the DNS server responsible for the relevant DNS records, called the authoritative server, which it then queries to retrieve the host to IP address mapping. This DNS process can be leveraged to detect attackers. Botnets regularly make use of the DNS for command and control and to perform reconnaissance on a destination organization [Choi et al. 2007; Oberheide et al. 2007]. These attack applications have characteristics that deviate from legitimate users. As an example, the recent Feederbot botnet issued customized DNS queries and bypassed its local ISP DNS resolvers to issue queries, likely to evade detection [Dietrich et al. 2011]. This provides opportunities to detect bots by profiling their queries and associations with DNS resolvers. However, no prior work has systematically determined the resolvers used by clients or the query patterns used by these resolvers, preventing such opportunities from being realized. At the same time, the DNS has received significant attention from researchers. Some prior work has studied DNS query performance, caching effectiveness, resilience of DNS servers, and even the contents of DNS servers. Other prior work has sought to leverage DNS in novel ways. In previous work, we proposed using the authoritative DNS server for access control, allowing it to provide accurate IP mappings as “keys” to reach protected servers, while churning server IP address to prevent access without the proper mapping [Shue et al. 2012]. These novel techniques require a detailed understanding of the DNS, both from an authoritative server and from a resolver standpoint. While our approach required cooperation from DNS resolvers, these very DNS resolvers appeared to be an understudied topic. Prior work did not address several key questions for us. In particular, we wanted to know if we could 1) distinguish a resolver on a (possibly malicious) end-user system from an ISP-class resolver, 2) associate a client with a particular resolver to create a narrow (and thus more secure) capability, and 3) build useful historical information about a particular resolver and the prior behavior of its clients. In this work, we broadly explore DNS resolvers to answer these questions. In doing so, we make the following contributions: